Cloud-based computing has become increasingly prevalent for enterprises. One important aspect of cloud-computing is scalability. By being able to provision new cloud resources on demand, and essentially in real-time, enterprises can achieve the cloud-computing benefits that they need and cloud providers can allocate their cloud resources as needed.
In a cloud environment, new assets may be provisioned (or spun up) rapidly, while other assets are discontinued. Assets may include cloud resources such as servers, databases, virtual machines having independent operating systems, containers sharing a common operating system kernel, serverless code segments, and more. In some environments, enterprises may provision numerous instances of the same asset in order to meet demand (e.g., provision hundreds of servers to accommodate anticipated demand from clients). Further, with the growing popularity of continuous delivery and continuous deployment software development practices, cloud assets may be automatically provisioned by enterprises once software has been tested or otherwise readied for deployment. Assets also may be deployed to perform the testing.
Although rapid provisioning of cloud assets can enable efficiencies for enterprises and cloud providers, it also poses security risks. Generally, when a new cloud asset is provisioned, it does not necessarily have the ability to communicate with other cloud assets. In particular, many cloud assets have security requirements that limit access to them, such as database passwords, secret API keys, per-user encryption keys, and other types of secrets. Such secrets must be secured and managed so that access to them is limited to users and applications that need them and are allowed to use them.
Existing security techniques include individually providing secrets or other credentials to individual cloud assets in order for them to communicate with other assets. Other approaches include providing initial secrets or credentials that are hard-coded into the system environment (e.g., in configuration files of cloud assets). Similarly, secrets or credentials may be written into the code of a new cloud asset when it is provisioned. Nevertheless, these approaches provide inadequate security, especially in dynamic cloud environments with rapidly changing deployments of cloud assets. For example, if a secret or credential is included in a file that is used by a cloud asset (e.g., an SSH key or encryption private key), it may be transmitted from asset to asset, thereby exposing it to possible interception or eavesdropping, and possibly contravening industry standards or government regulations (e.g., in defense or healthcare environments). Moreover, such secrets or credentials may be left in place for prolonged periods of time, thus exacerbating these security threats. These techniques are also inefficient, time-consuming, and resource-intensive.
A further security technique involves encrypting the data in a configuration file of a cloud asset, and then checking the code of the asset into a code repository. This is also problematic, however, because sharing the encryption key for the encrypted data is difficult. Further, even if the encryption key could be shared securely, a further problem arises: the requirements that cause secrets and other credentials to change are not necessarily synchronized with checking code into the code repository. For example, code developers may check code into a repository on an ad hoc basis, while requirements may dictate changing the secret or other credential at different times (e.g., upon detecting that an account was compromised, an auto-rotate policy for passwords, a shift to a new infrastructure provider or a new infrastructure, etc.). This can result in secrets or credentials for cloud assets being out-of-date and ineffective for actually achieving secure communications with other assets.
Thus, there is a need for technological solutions for securing an asset-to-asset cloud communication environment. As disclosed herein, this security can be automatically provided without the need for predefined secrets or credentials given to each cloud asset. Instead, based on an investigation of a cloud asset, and an authentication process for the cloud asset, a determination can be made whether the cloud asset should be able to communicate with another asset. The appropriate credential or other secret may then be provided, either directly to the cloud asset or to an intermediary system (e.g., credential vault), to enable the cloud asset to securely communicate with the other asset.